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(57) D^t dc mAadonndcs pour tm envifonoanent de 
divcloppcmcnl int^grd. Lc d6p6i est divisd en couches 
dc ra9on i d^ir des oiveaux de comporlcnient cominun 
utiks A difl&ents types d*outiIs de d^eloppement 
d 'applications. Lcs oui*\s d*uti!isatioD la plus gihi^rale 
om acc*s aux mitadormics au niveau dc types d stnicture 
simple; !es outils plus specialises oni accis a des 
composantes qui conticonent les propriAes d*un langage 
eibte; les outib dc haute specialisation ont accis i des 
metadonnees coraposees i parties segmenublcs qui 
peuvcnl scfvir i consti^ier des applications reparties. 



(57) A sietadaia repository Tor use in an integrated 
development environment in provided. The metadata 
repository is layered to defme kvcis of common 
behaviour useful lo different types of application 
development lools The mo^t general use tools have 
access to metadata at the level of simple constructed 
types; more ^)eciali3ed tools have access »o conponeatt 
that contain properties of a target language; highly 
^^ecialised tools have access to composed partitionable 
pan metadata that can be used for constructing 
distributed applications. 
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HIERARCHICAL METADATA STORE FOR AN INTEGRATED DEVELOPMENT 

ENVIRONMENT 

A metadata repository for use in an integrated development environment is provided The metadata 
repository is layered to define levels of common behaviour useful to different types of application 
development tools. The most general use tools have access to metadata at t^ level of simple 
constructed types; more specialised tools have access to components that contain properties of a 
target langurige; highly spedaBscd tools have access to composed partitionable pan metadata that can 
be used for constructing distributed applications. 
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HIERARCHICAL METADATA STORE FOR AN INTEGRATED DEVELOPMENT 

ENVTOONMENT 

Fidd of the Invention 

The present invention relates in general to the data processing field, and more spe:i5cally to the 
provision of an integrated tool development environment. 

Background of the Invention 

Traditional tool development follows the simple steps of creating the text-based source code, and 
then compiling and executing the code on a specific platform. The increasing complexity of function 
and integration of tools over multiple platforms means that tool development cannot generally be 
performed by small groups of human developers. Often the only way to produce a fully functioning 
application is to make use of specially-designed application development tools in order to build other 
tools. Today's applications ere built using a mix of low level tools such as source editors and 
debuggers, along with high level builders of user interface, data access, distribution support, and code 
generators. The applications buih in such environments are targeted to run in a multiplicity of 
execution environments, on various hardware platforms, supporting many distribution mechanisms 
and data access mechanisms. Developing such applications in the current "state of the art" requires 
the use of multiple different tools for multiple different vendors, each solving a piece of the over all 
puzzle. 

The ideal is to provide an integrated development environment (IDE) in which information provided 
by each tool during program development can be shared with other tools, particulariy those being 
used in the same development effon, to avoid duplication and inconsistent interface and function 
operations. Currently available development tools address only a small subset of this requirement. 
They typically focus on a source-level, single targeted application, and use a simple file system 
folder/directory model for thdr information. 
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Where the application development tc jls are tightly integrated, they can often use cross refercnne 
tables to share information about the program vr.drs rfevelopment However in an incremental 
development environment, the tables can be out of synch with the source code, and frequently contain 
less informatioti than implied by the source code. 

5 

Also, any tool not closely integrated (and this is often the case with tools from different 
manu&cturers) wiD have to parse the source or the tables, provided the programming language is not 
a barrier This parsing exposes the tool either to parsing differences or internal table definitions. 

10 Summary ftfi^,e Invfntinn 

One of the key problems that needs to be addressed during construction of an IDE for a complex 
application is the ability of the various IDE tools and components to share information in a 
meaningful way. An "information store" is required to facilitate this sharing Such a store must 
support usage and access characteristics of a multi tool/muiti user environment and provide a flexible 

1 5 basis for capturing required semantic information. 

The store must also define an overall mformation structure about applications under development, 
and organize it in a way that offers the degrees of freedom required by today's applications These 
degrees of freedom include choices of targets, languages, component models, distribution, etc. The 
IDE further needs to define a model for sharing common application semantics among the 
cooperating tools, but at the same time allow individual tools to extend the shared information with 
private tool data. The model also need to "manage" programming "element" naming issues (naming 
scopes) across the various domains inplied by the degrees of freedom. 

25 Therefore, an object of the present invention is to provide a mechanism for organizing metadata in 
support of the development of complex enterprise applications by defining a layered data model for 
handling application development metadata, addressing the various application degrees of freedom 
within a single metadata store. 
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In accordance with these objects, the present inventio.i provides a metadata container for common 
access tool data in an object oriented programming environment. The metadata container has a 
hierarchical structure that consists of simple constructed types containing subparts and encapsulated 
behaviour, components containing properties of a target language, and composed parts permitting 
5 partitioning for distribution. 

The present invention also provides a metadau store for conunon access tool data in a object oriented 
programming environment consisting of a single base class defining conunon behaviour for elements 
in the tool data, and separate abstract class hierarchies, inheriting from the single base class, to define 
1 0 name scope and containment for tool data. 

Brief Description of the Dra^ving^ 

Figure 1 is a schematic drawing illustrating categories of metadata lajjered "parts" according to the 
preferred embodiment of the invention, and 

15 

Figure 2 is a tree diagram illustrating the model layer hierarchy according to the preferred 
embodiment of the invention; and 

Figure 3 is a class diagram, expressed in C++, of an IDE element base class, according to the 
20 preferred embodiment of the invention 

Detailed Description nf t he Preferred Embodiment 

The preferred embodiment has been implemented as an open data model that provides source code 
or the common intermediate form accessible and extensible by all development tools that wish to 
25 work with a program The data model is language independent which allows cross system source 
sharing. This model could be use to drive a code generator. 

In the preferred embodiment, the data model provides a metadata store in support of a tool 
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integration framework which is (uijy described in our concirrentK filed application titled "An Object 
Oriented Framework Mechanism Providing Common Object Relationship and Context Management 
For Multiple Tools" (IBM Docket No. CA997.002). 

In order to handle the requirements of the range of applications, from basic source programming to 
component based visually constructed applications, the data model of the present invenrion provides 
a shared metadata store in v(*ich the development information Is layered. Each layer defines the 
common behaviour required at that level. Tools using the model start with a behaviour at a given 
layer and extend it as appropriate for the particular tool. 



The dau model captures information about various "elements" required during the development of 
an appBcation. This includes information abou* the logical pieces of an overall application, such as 
foiiers. ties and application paiu. At its highest level, the data model generally defines the common 
behaviour required to be recognized as an element within the integrated development environment 
1 5 This includes the ability for rendering the element, exposing its contem (if appropriate), as well a 
triggering any of its actions. 



This is roughly equivalent to other currently available application development information stores that 
map to a file system (source files and directories/folders) However the data model of the invention 
20 is fiirther extended into key areas. 

1 recognition of namespaces as distinct from folder coniainment; and 

2 refinement of the application "pan" concept into distinct part layers. 



Rather than leaving it to the developer to recognize project folder containment and appfication part 
naming at the source or force the naming relationships to be the same as the folder containment, the 
data model of the present invention defines name scope as a "parallel" set of relationships to that of 
containment. This allows, for example, a part containing a C++ class A: :B:.C to be properly defined 
as a series of nested naming scopes, while at the same time allowing the same part to be used 
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(through containment or linking) within several project folders. 

The data model oi the invention supports application definition and assembly from parts. According 
to the invention, a part is a self contained piece of an overall application that is distinct from the 
source files that contain the source code for the pan. Depending on the programming environment, 
a part m^y in fact reference several files (hr example in C^. the hpp and cpp files) but a part is not 
a file contarner. Within the data model of the invention, a part is a separately editable piece of 
application definition (metadata) distinct from any source files that may be associated with the part 
or generated from the part definition. As will be discussed in more detail below, within the data 
model of the invention, all parts are named and name scoped A pan (based on its implementation) 
may itself be a name scope for other pans, as in, for example, C++ nested classes 

The layering approach to a metadata store is schematically illustrated in Figure 1 . The semantics of 
a pan 1 are layered in a spectrum in the data model from parats used by generdi use tools to pans 
used by increasingly specialised tools 

At the general end of the spectnim, GcneraKsed Parts 2 are base pans corresponding to the semantics 
of a constructed type within the target language The list of generalised parts include subparts and 
encapsulated behaviour such as methods and inheritance Typically, these correspond to a class 
definition for objea oriented languages such as C++ and Java™, or to some form of a structure, such 
as in COBOL. 

A degenerate case of the generalised parts arc various types supported by the data model These 
types are fiirther specialisations of generalised parts that capture or encapsulate the following 
concepts: fiindamental types (eg. int, chpr) are represented by Primitive Types 4. records are 
represented by Streets 3; overlaid memory structures are represented by Unions 7; named cardinal 
Values are represented by Enumerations (Enums) 6; and aliased parts are represented by Type 
Definitions (Type DeO 5. 
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Component parts 8 are base name parts with the additional support of a component model A 
component part, regardless of its ultimate source language implementation, defines its external 
behavicur as a set of attributes which are called -properties", events raised by the part and actions 
which are externally triggerable behaviour The data model captures this information as a component 
pan and allows the generaUon of the appropriate target component model (eg Java Beans. IBM® 
VBE model, etc.). Whhin an IDE. this typically represems the level of support used by higher order 
"builder" tooli Componem parts are referred to within the data model as "builder consumable" parts, 
in relation to Hgure 2. 

Partitionable containers 9 are component parts that expose part of their in.emal behaviour to a level 
that allows repartitioning of the part for distribution. Through the data model, these parts expose 
interactions among their aggregated subparts, as well as interactions across parts This level of 
information is used to capture the application distribution structure regardless of the target 
distribution mechanism. 

Depending on its specific requirements, a tool selects the appropriare level of parts support to store 
its tod pan metadata within the data model. Shared behaviour is inherited from the data model, and 
the tool adds ft own extensions as appropriate. Typically, these extensions are opaque tool-specific 
properties. For example, this structure allows a data access part which is a component part 
containing infom»tion about access to a data base, to be consumed by a user-interface (UI) builder 
producing a UI part. The UI builder is a composed part containing the data access part and UI 
contTob TOs can subsequently be partitioned into a client part (UI and server call) and server part 
(server logic) and «xess to dau base. This is .11 done by editing , he data model information The 
«me dau model infomution can be used to generate a Java bean wi.h RMI call to server and JDBC 
«cess to data base, or a C++ client with DCE access to a server with a local data base 

The preferred embodiment is impler^,ed in an object oriented programing hierarchy which 
fiKihtates the sharing of parts through inheritance. Figure 2 illustrates .-n approach to data model 
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layers according to the preferred embodiment providing a class defir Jtion a« each layer and illustrating 
how the class of metadata, at that level in the hierarchy, can be used by tools. 

The most abstract b?se class, the IDE Element 20. is provided for the implementation of ai< il)E tree 
view. Using mostly pure virtual method',, it permits the tree view to display the contents of the 
model, launch actions against its elements (nodes), and attempts structural changes against the 
hierarchy without regard to the content details Success of these operations (especially structural 
changes) depends on the supported semantics of the individual tree element derivations. 

The common behaviour of rendering of tree nodes is defined so that each clement within the tree view 
wfll show Us name, icon, indication whether element is owned or linked, %rd an indication whether 
the element can be further expanded. 

The basis for expanding branches of the tree view is the ab.lity to list the contents of any one IDE 
element as its contained element. Thus, the IDE Element base class 20 provides a common behaviour 
to expose content This is iflustrated, in the preferred mbodiment, in '.h- sample C++ header file for 
an IDE Element base class set out in Figure 3. Each derived IDE element determines what 
constitutes its content. Unlike most other relationships supported within the model, the "contains" 
relationships have a requirement for supporting direct access to its element by name, as well as 
providing cursor based access that maintains ordering This is required because the tree view is 
expected to allow the nodes whhin the tree to be reordered using drag and drop operations or the 
selection of reordering actions. The relative element order is maintained within the model A specific 
example of this Is a visual builder pallet comaining pallet categories, each of which contains pans 
available to the buUder. Frequently used items would be expected to be placed at the top of the list 
to reduce the need for scrolling. 



model also provides a set of methods at this level of abstraction that allow modifications to the 
structure without regard to element details The success of these operations is determined by 
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the derived implementations There are two mechanisms for constructing container relationships: 
1 Ownership relationships indicating aggregation of the sub elements within the subject parts. 

Owned elements are destructed if orphaned by a parent; and 

2. Reference relationships indicating soft links or shadow links to a sub element owned or 

aggregated elsewhere within the tree. 

In all cases, a removal action on one element propagates the removal action across ownership 
relationship but not reference relationships. That is owned elements are destructed but in the case 
of linked elements only the link is removed. It should be noted that the data model does not enforce 
1 single owning parent rule, although a great majority of owning relationships are expected to be of 
this type In an owning relationship, the child is destructed when any parent is destructed or when 
the child is explicitly orphaned by any owning parent. 

Since derived implementation may reject attempt to change the contents of th.-^ tree nodes, methods 
arc provided to check if the desired operation is allowed. Even if the operation is allowed it may still 
6D for other reasons The decision to accept or reject a content action is up to the object that is the 
recipient of the content, that is the parent object would be asked for permission not the child object. 

In the preferred embodiment, the IDE Element base class 20 provides additional common behaviour, 
including: 

1 action support: the model provides a mechanism for triggering edit actions against the 
model objects. The term "edit" simply means any tool specific action Each tool is expeaed to 
provide an implementation of the edit methods in their concrete class derivations 

2 code generation support: each element can cause source output to be generated for the 
model metadata A default implementation of gei.erate 0 is to simply return. If output must be 
produced, the derived implementation need to over ride the generate Q method. This generate () is 
a context sensitive method 

3. "dirty" part support an IDE element can be marked by a tool as being "dirty" This 
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indicates that the source code for the clement must be regenerated because it or its dependencies have 
changed. The model provides a method to manage this indication shown in Figure 3. 

4. associated file operation the model makes the distinction between contained and 
associated files A contained file is simply an IDE element that is stoicturally related to its container. 
5 An example is the source files contained within a project group folder. Contained files are 
manipulated using the content and structural operations discussed earlier in this section. An associate 
file is a file reference that is required to fiirther define the IDE element h is asi:ociated with. An 
example of an associated file or header files required in order to use a part, or source files generated 
firom a group or a part. When most cases these are not actually contained within the element with 
1 0 which they are associated. 

At the next level of abstraction are the Containment Scope 22 and ' Jame Scope 24 base classes. As 
mentioned above, containment and part naming are paraJlel. and therefore, independent relationships 

15 On the containment scoping side, the base class 22 represents a generalized groining construct. In 
its dcfauh form, it ajlov^ an aibitraiy coUection of groups, parts and fiies that can be owned or linked. 
Also by dcfeuk, its content can be ''edited** through the tree view or a tr >I action. This is a genera! 
"folder" 40 construct within the IDE. 

ZO The base Name Scope class 24 defines support for nested name scopes within the prefened 
embodiment model Its primary intent is scoping of name parts The Name Scope Folder 26 and 
Named classes are used to constnict the hierarchy reflecting the definitional scopes of the parts. This 
hierarchy is parallel to that of containment, to allow name scoping to be independent of part 
cc-^tainment. 

15 

The Namescopc Folder class 26 is in all aspects identical to the Comainment Scope class 22. except 
it also defines a name scope Namescope Folder 26 is to allow name scope other than name groups 
and the derivations and parts in their derivations This is a general names based construct within the 
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Scoped names are constructed by assembling a nested set of scopes using the group and pan 
constructs. Model, the singleton basis of the structure, plays the role of the global naming scope 
Consta^ctors are provided on group and p«t derivations that allow specification of the parent name 
scope for the item being constructed If a ™ime scope for these objects are not specified the 
constructed objeas are defined at a global scope, that is created below model in the name scoping 
hierarchy. 

In general, tree nodes also act as local name scopes for the immediate children they contain By 
default, children of an element must have unique names. Since part names are globally unique (under 
the name scoping mechanism), the defauh model implementation vAW allow a pan to be crtated 
.ndependent of any non-pan construa that may exist with the same n«„e but will not allow a part 
to be stored in an element container if the comainer already has a non-p... child with the same name. 

Continuing in .he Name Scope hierarchy, the Named Part class 28 represents a generalized part 
construct 44. By defauh. its content is editable only via an explich tool action. The part class is not 
a folder, although it may be defined as an aggregate of sub-parts. 

The Named Pan class models are based constructed type, and pennits the data model to capture 
.nformation about model defined attributes and properties, inheritance, data member and sub-part 
a^regafon, and externally triggerable behaviour or methods. All part, can act as name scopes for 
Other parts. 



model 
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The Builder-Consumable Part class 32 implements semantics of a component part. These builder 
parts are consumable by the visual composition editor (graphical composer) They are defined in 
terms of attributes, events and actions At generation time. Builder-Consumable parts fean re maps 
to the appropriate target component model 46. 

n>c Builder-Composed Part class 34 is a partition class that defines the semantics of a partitionable 
composed part, as distinct from a distributable pan It should be pointed out that a part is 
distributable if builder tools ire allowed to use a proxy to access a remote instance of the pan. In the 
data model, this is indicated by a part property. A part is partitionable if distribution support can 
effectively rearrange the part content across two or more parts Concrete parts derived from this 
class map to composed parts 48 and are partitionable by distribution support. 

Local associations among a part's sub-parts are captured within the part definition. They represent 
sub-part interactions Methods are provided to handle the repartitioning of a part which occurs by 
redeploying a sub-part from one part to another If this redeployment is successfiil. a distributed 
association between the parts is created These represent distributed cross part interactions between 
sub parts of differetit parts. 

A final base class is the Fil« Reference c ass 36 which represents a generalized file reference construct. 
It is a symbolic pointer to a file item 50 in the file system. 

Embodiments of and modifications to the described invention that would be obvious to those skilled 
in the art are intended to be covered by the appended claims. 
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The embodiments of the invention in which an exclusive property or pri\ilege is claimed are defined 
as follows: 



1 A metadata container for common access tool data in an object oriented progrzmming 
environment, having a hierarchical structure, comprising: 

simple constructed types that contain subpans and encapsulated behaviour, 
components that contain propenies of a target language, and 
composed parts that permit partitioning for distribution. 

2 A metadata store for common access tool data in an object oriented programming 
environment, comprising: 

a single base class defining common behaviour for elements in the tool data, and 
separate abstract class hierarchies, inheriting from the single base class, to define name scopes 
and containment for the tool data. 

3 A metadata store, according to claim 2, wherein the abstract class hierai chy to define name 
scopes comprises: 

a part class representing a generalized pan construct adapted to contain subparts and 
encapsulated behaviour. 

4 A metadata store, according to claim 2 cr 3, wherein the abstract class hierarchy to define 
name scopes comprises: 

a component class adapted to implement properties of a target language. 

5 A metadata store, according to claim 2 or 3, wherein the abstract class hierarchy to define 
name scopes comprises: 

a partition class adapted to contain definitions of part partition semantics 
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6. A metadata store, according to claim 2. wherein the abstract class hierarchy to define name 
scopes stratifies the tool data into a Isytxtd structure, comprising: 

simple constructed types that contain subpans and encapsulated behaviour, 

components that contain properties of a target language; and 

composed parts that permit partitioning for distribution. 
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FIGURE 1 
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FIGURE 2 
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